AD - Creating GPOs

Scenario

NetLab LLC is looking for ways to manage their computers in a way that is fast and efficient. To do this, they have brought in a team to set up an Active Directory domain controller that will manage their nearly 20 employees. The IT supervisor for NetLab LLC wants to set up Group Policy Objects so that they can best manage the company workstations and users as they grow. To start, we are tasked with setting up a policy that will prevent sales department employees from changing their desktop wallpaper. The company wants the brand logo to remain on all sales workstations to present the best image possible to customers and clients. The company would also like us to configure the policy to block access to the Control Panel and PC settings for everyone except administrators.

Environment

• Proxmox
• Network Lab LAN
• NetLab.private
• Target: All sales staff members
• Domain Controller: DC01

Creating the GPO (Group Policy Object)

The administrator for NetLab LLC has set up several organizational units, also known as OUs, to organize the company. These include a sales team, IT department, HR department, finance department, and managers. In addition to this, separate OUs have been created for servers, workstations, and service accounts to keep things clean and easy to manage.

All GPO work is done inside the Group Policy Management Console, also known as GPMC. This is a separate tool from Active Directory Users and Computers and is the only place where policies can be properly created, configured, and linked to OUs. To open it, run gpmc.msc on the domain controller or locate it in the tools tab inside the server manager.

Inside GPMC, locate the Sales OU in the left side tree, right-click it, and select Create a GPO in this domain, and Link it here. Name the new policy POL_DesktopLockdown so it is easy to identify later. This single action both creates the policy and links it to the Sales OU at the same time.

Configuring the GPO Settings

Right-click POL_DesktopLockdown and select Edit to open the policy editor. To lock down the desktop wallpaper for sales users, navigate to User Configuration → Policies → Administrative Templates → Desktop → Desktop. Look for Desktop Wallpaper and enable the setting. A specific wallpaper image path can be entered here if desired. Leaving it blank will result in a black desktop.

To reduce the risk of users making changes that could affect their workstation, the company also wants us to block access to the Control Panel and PC settings. Navigate back one level to Control Panel and enable Prohibit access to Control Panel and PC settings. Since both settings live inside the same policy, they will apply to the same target, which is our Sales OU.

Update and Verify

With the policy created and configured, log in to a workstation as one of the sales team members. The first sign that the policy is working will be a black desktop or the configured wallpaper appearing. If the policy does not appear to have applied yet, open a PowerShell window and run gpupdate /force to tell the workstation to pull the latest policies from the domain controller. Then log out and log back in, since user side policy settings fully take effect at logon rather than immediately after an update.

To confirm the Control Panel restriction is working, attempt to open the Control Panel. An error should appear stating that the action has been blocked due to restrictions on the computer. Once the sales user session is confirmed working, log in as a member of the IT team and verify that neither restriction applies to them and that they can freely change the wallpaper and access PC settings.

Wallpaper locked down on a Sales user workstation

Problems Encountered

The main issue I ran into during this lab was understanding the difference between GPMC and Active Directory Users and Computers. Early on, I was attempting to create and link policies from the wrong tool entirely, which caused a lot of confusion. Once I understood that GPMC is the correct place for all policy work, things became much clearer.

The second problem was with how GPO links work when applied to a parent OU. I initially created the policy and linked it to the company level OU, which is NetLabLLC. Because policies flow downward through the OU structure by default, this caused the restrictions to apply to every department, including IT. The fix was to remove the link from NetLabLLC and keep it only on the Sales OU, which limited the policy to sales staff only.

This turned out to be a valuable lesson. In a real environment, linking a policy too high in the OU structure without thinking through the impact can unintentionally restrict users who were never supposed to be affected.

Closing Notes

This lab introduced the core workflow for managing computers and users through Group Policy. The key takeaway is that GPMC and Active Directory Users and Computers serve very different purposes. ADUC handles identities, meaning users, groups, and OUs. GPMC handles rules, meaning what those users can and cannot do on their machines.

It is also worth noting that policy settings under User Configuration follow the user account, not the computer. This means the OU that matters for targeting is the one the user account lives in, not the one the computer object sits in. Keeping that distinction in mind will make troubleshooting much easier in future labs.

Finally, after making any policy change, always run gpupdate /force on the target machine and then do a full log out and log back in before assuming something is or is not working. Many policy settings only fully apply at logon, and skipping that step is one of the most common reasons a policy appears to have no effect.